- 
                Notifications
    You must be signed in to change notification settings 
- Fork 242
feat: add telemetry scheduler #1107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
| Codecov Report❌ Patch coverage is  Additional details and impacted files@@            Coverage Diff             @@
##           master    #1107      +/-   ##
==========================================
- Coverage   86.93%   86.79%   -0.14%     
==========================================
  Files          60       62       +2     
  Lines        5555     6067     +512     
==========================================
+ Hits         4829     5266     +437     
- Misses        540      585      +45     
- Partials      186      216      +30     ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
 | 
6c1fff1    to
    2e16e4f      
    Compare
  
            
          
                internal/telemetry/scheduler.go
              
                Outdated
          
        
      | } | ||
|  | ||
| func (s *Scheduler) processNextBatch() { | ||
| s.mu.Lock() | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we even need a mutex? Is it even possible for this function to be called concurrently by 2 different goroutines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation seems reasonable.
Left some comments.
I don't like too much how we need to store the dsn and sdkInfo in the scheduler.
We probably don't need to add too much stuff to it so it's okay if we cannot get rid of it.
663a9eb    to
    cda84db      
    Compare
  
    | type logJSON struct { | ||
| Timestamp *float64 `json:"timestamp,omitempty"` | ||
| TraceID string `json:"trace_id,omitempty"` | ||
| Level string `json:"level"` | ||
| Severity int `json:"severity_number,omitempty"` | ||
| Body string `json:"body,omitempty"` | ||
| Attributes map[string]protocol.LogAttribute `json:"attributes,omitempty"` | ||
| } | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I see the reason why we need this type now, e.g. Timestamp is a time.Time but you want to serialize it as float64, etc.
In Rust (serde) you could do this using serialize_with: https://serde.rs/field-attrs.html#serialize_with 😎
| envItem, err := item.ToEnvelopeItem() | ||
| if err != nil { | ||
| debuglog.Printf("error converting item: %v", err) | ||
| debuglog.Printf("error converting item to envelope: %v", err) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| debuglog.Printf("error converting item to envelope: %v", err) | |
| debuglog.Printf("error converting item to envelope item: %v", err) | 
or
| debuglog.Printf("error converting item to envelope: %v", err) | |
| debuglog.Printf("error converting item: %v", err) | 
I guess
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed the diff, Looks Good To Me.
Description
Add telemetry scheduler implementation and integrate with the client. The current PR also includes changes on the transport and envelope layer.
The proper solution for batching under the scheduler is to abstract each event type, so that it knows how to convert itself to an envelope item (noted as EnvelopeItemConvertible in the PR), and then the scheduler would just create envelopes using
[]EnvelopeItemConvertible. This partially fixes the issue, since currently everything is anchored around theEventtype. We should also abstract all event types to implementEnvelopeItemConvertiblein the future.Notes
EnvelopeConvertibletoEnvelopeItemConvertibleintroduced in feat: add new envelope transport #1094. For the sake of clarity I added the changes here and not on the other PR. Same applies withToEnvelopeEnvelopeHeader. Left some comments on the implementation.Issues